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Die f olgendan Angaben sind dan vom Anmeldar aingaraichtan Untarlagan antnomman 

Prufungsantrag gem. § 44 PatG ist gestellt 

@ Verteiltes Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersystem 
(g) Die Erfindung bezieht sich auf ein verteiltes Fahrzeug- 

informationsverarbeitungs- und Fahrzeugsteuersystem 

mit wenigstens einem fahrzeugseitigen, ersten System- 

tei'l und wenigstens einenn weiteren, zweiten Systemteil 

zur Ausfuhrung einer oder mehrerer fahrzeugbezogener 

Anwendungsfunktionen, wobei die Systemteiie uber ein 

zugehoriges Datenubertragungsnetzwerk miteinander 

kommunizieren. 

ErfindungsgemaS besitzen die Systemteiie einon kompo- 
nentenbasierten Aufbau aus verschiedenen, miteinander 
kommunizierenden Komponenten zur Ausfuhrung ver- 
schiedener Funktionen, bei dem jede Komponente eine 
Funktionsaufruf-Schnittstelle, uber welche die von der 
Komponente ausgefuhrte Funktion von anderen Kompo- 
nenten desselben oder eines anderen Systemteils aufruf- 
bar ist, und eine Konfigurations-Schnittstelle aufweist, 
uber die ihre Konfiguration variabel festlegbar ist. Hierzu 
ist eine Konfigurationsmanagereinheit vorgesehen, wel- 
che die Komponenten uber diese Schnittstelle in Abhan- 
gigkeit davon konfiguriert, welche anderen Komponenten 
im System vorhanden sind. 

Venwendung z. B. fur ein verteiltes Informationsverarbei- 
tungs- und Steuersystem fur Automobile. 
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Beschreibung 

Die Erfindung bezieht sich auf ein verteiltes Fahrzeugin- 
formationsverarbeitungs- und Fahrzeugsteuersystem nach 
dem Oberbegriff des Anspruchs 1. 

Ein solches System beinhaltet weaigstens zwei uber ein 
Dateniibertragungsnetzwerk kommunizierende Systetnteile 
als Netzknoten, von dehen mindestens dner fahrzeugseitig 
. angeordnet ist. Das System insgesamt dient der Ausfiihrung 
fahrzeugbezogener Anwendungei^der vorschiedensten, fiir 
^Fahrzeuge relevanten Arten, wie im Zusammenhang mit 
Benutzerschnittstellen, intemer und extemer Kommunika- 
tion, Anwendungsunterstutzung und mit den eigentlichen 
Anwendungen bzw. Diensten selbst, z. B. Ansteuerung von 
Fahrzeugaggregaten, Auswertung von Fahrzeugsensorinfor- 
mationen und ailgeraeine Dienste, wie Navigation, Dia- 
gnose, Diebstahlschutz und Datenaustausch mit entfemten 
Netzwerkknoten z. B. iiber das Internet. 

Modeme Fahrzeugsysteme zeichnen sich durch einen im- 
mer groBer weidenden Datenverarbeitungsanteil, d. h. eine 
zunehmende Bedeutung von Telematikanwendungen aus. 
. So verlangen z. B. Pannenhilfsdienste und dynamische Na- 
vigationsdienste ebenso wie Intemet-basierte Anwendungen 
die Realisieiung verteilter Systeme, bei denen das Fahrzeug 
I nicht mehr als isoliertes Einzelsystem, sondern als aktiver 
Knoten in einem veiteilten Datenkonmiunikationssystem 
mit vorzugsweise weltweiter Reichweite betrachtet wird. 
Fahrzeugseitig implementierte Systemanwendungen wer- 
den dabei im allgemeinen sowohl Client- als auch Server- 
funktionen ttbemehmen. 

Bei einem in der Offenlegungsschiift D£ 196 25 002 Al 
offenbarten Fahrzeugkommunikationssystem ist bereits eine 
Schichtung von fur ein Fahrzeugsystem notwendigen Funk- 
tionalitaten vorgeschlagen worden, die unter Einsatz einer 
adaptiven Applikationssteuerung eine gewisse VariabilitSt 
in der Zuotdnung der Anwendungoi zu verschiedenen 
Schnittslellen und fahrzeugseitigen Geratednheiten erlaubt 
Auf dem Gebiet der allgemeinen Datenverarbeitung ist in 
jiingerer Zeit altemativ zu zentralen Systemarchitekturen 
ein komponentenbasierter Systemaufbau voigeschlagen 
worden, siehe beispielsweise den Zeitschriftenaufsatz D. 
Kiely, "Are Components - The Future of Software?", IEEE 
Computer Magazine, Seite 10, Februar 1998. Dabei wird die 
vom Gesamtsystem zu eibringende Funktion mittels De- 
komposition in einzelne Funkdonskomponenten zerlegt, die 
dann durch geeignete Verkniipfung und Kommunikation un- 
tereinander die gewiinschte Gesamtfunktion erbringen. Die 
Aufteilung in Komponwiten vereinfacht dabei zum einen 
^ die Wiederverwendung derselben und das Aufbauen kom- 
piexer Systeme aus diesen Komponenten und zum anderen 
das Erstellen von robusten Komponenten selbst, da diese 
nur mit einem begrenzten und uberschaubaren Funktions- 
umfang ausgestattet weiden miissen. Charakteristisch ftir 
die Komponenten ist ihre nach auBen gleichartige Architek- 
tur, die es auf einfache Weise ermoglicht, sie untereinander 
zu verkniipfen, wobei die von einer Komponente erbrachte 
Funktion zunachst unabhgngig von dieser Architektur gese- 
hen werden kann. 

Das explosive Wachstum des Internet bzw. des World- 
Wide- Webs hat dazu gefUhrt, daB verteilte Systeme zun^- 
mende Bedeutung gewinnen. Um die Realisierung solcher 
Systeme zu erleichtem und um komponentenbasierte Sy- 
stem umsetzen zu kdnnen, haben sich immer mehr verteilte 
Objektmodelle etabliert. Die Systementwickler stiitzen sich 
dabei immer starker auch auf Intemet-orientierte Ldsungen 
fiir diese Objektmodelle und realisieren sie z. B. mit Java 
, RMI bzw. "Java Beans", siehe entsprechende Inlemet-Infor- 
madonen der Firma Sun Microsystems, mit DCOM von Mi- 
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crosoft, siehe die Veroffentlichungen T. Albertson, "Best 
Practices in Distributed Object Application Development: 
RMI, CORBA und DCOM, Februar 1998, Intemet-Seite 
"http://developer.com/news/techfocus/022398_distl.htm" 
5 und R E. Chung et al., "DCOM and CORBA Side by Side, 
Step by Step, and Layer by Layer, September 1997, Internet- 
Seite "http://www.cs.wustl.edu/ schmitt/submit/Pa- 

p«r.html", Oder auf Basis von CORBA, siehe auch A. >fogel, 
K. Duddy, "Java Programming with CORBA", John Wiley 
10 & Sons, 1997. 

Wie aus der genannten Literatur deutlich wird, ist der 
Trend hin zu objektorientierten Komponentenmodellen 
durch die folgenden Vorteile erkiarban Erstens durch die 
Wiederverwendung existierender Algorithmen bzw. Soft- 
15 ware und damit verbunden durch die Maglichkeit zum "ra- 
pid prototyping" von Anwendungen durch "plug-and-play"- 
Interaktion der Komponenten; zweitens durch voncinander 
unabhangige Entwicklung und Implementierung von Kom- 
ponenten; drittens durch effiziente Code-Wartung inklusive 
20 der systematische Verleilung von Aktualisierungen bzw. 
"Updates"; und viertens durch "Lightweight"- und "Thin 
clients"-Realisierungen, die mit infrastrukturbasierten Sy- 
stemen kommunizieren, die dort an verschiedenen Stellen 
lokalisiert sein konnen. Eine der charakterisierenden Hgen- 
25 schaften von Komponenten besteht darin, daB sie einer ein- 
heitlichen Architekturvorgabe folgen, die es erleichtert, sie 
zu einem Gesamtsystem zusanunenzufugen. Dabei hat diese 
Architektur primar nichts mit der eigentlichen Funktion der 
Komponente zu tun. Sie legt vielmehr fest, wie die Kompo- 
30 nenten miteinander agieren, aber nicht woriiber sie sich "un- 
terhalten". Diese Charakterisierung gilt unabhangig davon, 
ob die konkrete Komponente in Software odst Hardware 
realisiertist. 

Der genannte Trend zu Komponentenmodellen auBert 
3S sich in der zunehmendra Bedeutung von Tschnologien, die 
vert^e Komponentensysteme unterstQtzen, wie "Java Re- 
mote Method Invocation (RMI)" als Basis fUr die JavaBe- 
ans-Komponenten, "Commcm Object Request Broker Ar- 
s chitecture (CORBA)" und "Distributed Component Object 
40 Model (DCOM)" von Microsoft zur Realisierung von Acti- 
veX. Alle diese Modelle folgen dem Client/Server-Ansatz. 
Bisheiige Fahrzeuge sind, wenn sie am Ende der Produktion 
dem Kunden iibergeben werden, in ihrer FunktionalitUt be- 
zuglich ausfiihrbarer Dienste relativ stark fixiert. In Zukunft 
45 werden im Fahrzeug jedoch immer mehr Dienste zum Ein- 
satz kommen, wie sie auch in der Biiro- und Geschaftswelt 
Verwendung finden, die im Moment der Fmigstellung des 
Fahrzeugs aber haufig noch gar nicht existieren. Der Kunde 
wird daher haufig den Wunsch haben, zur Lebenszeit des 
50 Fahrzeugs dieses mit entsprechenden neuen Diensten nach- 
riisten zu konnen. Erfolgt die Nachriistung durch zusatzUch 
in das Fahrzeug eingespielte Software, so reicht hierftir ir- 
gendwann der dafiir notwendige Speicherplatz im Fahrzeug 
nicht mehr aus. Eine Nachriistung mit zusatzlicher Hard- 
55 ware ist hingegen vergleichsweise kostenintensiv und feh- 
leranfallig und verlangl in den meisten Fallen einen Werk- 
stattaufenthalt. Es besteht daher Bedarf an Systemen, die re- 
lativ einfach mit zus&tzlichen Funktionen nachriistbar sind, 
die beispielsweise als Software-Bausteine realisiert sind, so 
60 daB keine Hardware-Modifikation notig ist. Des weiteren ist 
es wiinschenswert, das System durch dynamische Verlage- 
rung vorzugsweise der Software-Bausteine zur Laufzeit des 
Fahrzeugs von oder zum fahrzeugseitigen Systemteil opti- 
mal an sich andemde Anforderungen bzw. Bedingungen an- 
65 passen zu kdnnen. Dies triffl beispielsweise ftir wechselnde 
Bedingungen bei der drahtiosen Konununikation zu. Ist nur 
eine schmalbandige Konmiunikationsstrecke vorhanden, 
sollte so wenig wie mdglich Konununikation betrieben und 
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so viel wie moglich notwendige Software im Fahrzeug un- 
Icrgcbracht werden. 1st hingcgcn cine KorninunikaLionsvcr- 
bindung mil hoher tJbertragungskapazitat vorhanden, kann 
gewisse Bearbeilungssoftware giinstiger in einem fahrzeu- 
gextemen Systemteil untergebracht sein, um die dort meist 5 
groBeren Rechenkapazitaten ausnutzen zu konnen. 

Der Erfindung liegt daher als technisches Problem die Be- 
reitstellung eines Fahrzeuginformationsverarbeitungs- und 
Fahrzeugsteuersystems der eingangs genannten Art zu- 
grundc, das in seiner Struktur zur Erflillung unterschiedli- 10 
cher fahrzeugbezogener Anwendungen vergleichsweise fle- 
xibel so aufgebaut ist, daB ein Nachriisten mit weiteren 
Funktioncn iiiit relativ gcringcm Aufwand moglich ist und 
die Voraussetzung geschaffen ist, die AusfUhrung der gefor- 
derten Anwendungen dynamisch und flexibel zwischen den 15 
Systemteilen variabel aufteilen zu konnen und das Fahrzeug 
als aktiven Netzknoten in ein gegebenenfalls weltumspan- 
nendes Datennetzwerk integrieren zu konnen. 

Die Erfindung lost dieses Problem dutch die Bereitstel- 
lung eines Fahrzeuginformationsverarbeitungs- und Fahr- 20 
zeugsteuersystems mit den Merkmalen des Anspruchs 1. 
Die Systemteile dieses verteilten, fahrzeugbezogenen Sy- 
stems haben charakteristischerweise einen komponentenba- 
sierten Aufbau aus verscbiedenen, miteinander koimnuni- 
zieienden Komponenten zur Ausftihrung der verschiedenen 2S 
gewtinschten Anwendungsfunktionen. Jede dieser so defi- 
nierten Komponenten, die vorzugsweise in Software reali- 
siert sind, besitzt einerseits eine Funktionsaufruf-Schnitt- 
stelle, Ciber welche die von der Komponente ausgefiibrte 
Funktion von alien aktiven Knoten des Netzwerks abrufbar 30 
ist, und eine Konfigurations-Schnittstelle, uber die ihre Kon- 
figuration variabel mittels einer zu diesem Zweck vorgese- 
henen Konfigurationsmanagereinheit fesdegbar ist. Dazu er- 
halt die Konfigurationsmanagereinheit Kenntnis uber die im 
System vorhandenen Komponenten und konfiguriert die je- 35 
weilige Komponente iiber deren Konfigurations-Schnitt- 
stelle in Abhangigkeit davon, welche anderen Komponenten 
vorhanden sind. Mit dieser Konfigurationsmanagereinheit 
kann folglich eine Komponente, die neu in einen Systemteil 
eingebracht wird, sei es durch Nachriistung des Systems mit 40 
derselben oder durch Verlagerung aus einem anderen Sy- 
stemteil, so "hinein konfiguriert" werden, daB sie optimal mit 
den ubrigen vorhandenen Komponenten kommunizieren 
kann. Die Einpassung der neuen Komponente in den betref- 
fenden Systemteil kann gegebenenfalls zusatzlich eine Mo- 45 
difizierung der Konfiguration einer oder mehrerer der be- 
reits zuvor vorhandenen Komponenten beinhalten. Durch 
diesen Aufbau lafit sich das fahrzeugbezogene System mit 
einer allgemeinen Datenverarbeitungs-Plattform ausriisten, 
die ein flexibles Nachladen weiterer, ausfiihrbarer fahrzeug- SO 
bezogener Anwendungen zu jedem Zeitpunkt wahrend der 
Lebensdauer des Fahrzeugs und ein kostenoptimiertes Rea- 
gieren von Dienstausftihrungen auf variable exteme Bedin- 
gungen ermdglicht. 

Bei einem nach Anspruch 2 weiteigebildeten System ist 55 
fur den jeweiligen Systemteil ein Komponentenlader voige- 
sehen, in der allgemeinen EDV auch als "Badewanne" be- 
zeichnet, der die jeweiligen Komponenten aufhinimt und 
Uber den diese mit einem Betriebssystem des Systemteils 
kommunizieren, an das andererseits je nach Systemteil ver- 60 
schiedene exteme Gerateeinheiten angekoppelt sind. 

Bei einer Weiterbildung des Systems nach Anspruch 3 ist 
eine funktionsorientierte Hierarchie der Komponenten in 
fahrzeugbauteilbezogene Komponenten oder "Tnterface"- 
Komponenten, die sich eng an den vorhandenen Hardware- 65 
Fahrzeuggerateeinheiten orientieren und zum Beispiel den 
ZugrifT auf Hardwarc-Schniltstellcn fur Kommunikations- 
gerate oder die Anzeige- und KontroUgerate einer Benutzer- 



schnittstelle realisieren, in Aggregations- Komponenten, die 
Dicnsle anbieten, welche Rohinfonnationen aus den fahr- 
zeugbauteilbezogenen Komponenten aggregieren, und in 
iibergeordnete Anwendungs- Komponenten voigesehen, 
welche die eigentlichen Dienste reprasentieren und die so- 
wohl auf die Aggregations- Komponenten als einer Zwi- 
schenschicht als auch auf die fahrzeugbauteilbezogenen 
bzw. Benutzerschnittstellen-Komponenten Zugriff haben. 

Bei einem nach Anspruch 4 weiteigebildeten System sind 
Miltel zum dynamise hen Verlagcm einer oder mehrerer der 
Komponenten zwischen den beteiligten Systemteilen wah- 
rend der Systendaufzeit und damit insbesondere zu beliebi- 
gen Zeiten wahrend der gesamten Lebenszeit des Fahrzeugs 
vorgesehen. Diese Komponentenverlagerungsmittel nutzen 
die Tatsache, daB die Komponenten mit einer Konfigurati- 
ons-Schnittstelle versehen sind und iiber diese variabel in 
eine neue Komponentenumgebung eines anderen System- 
teils "hineinkonfigurierbar" sind. Dadurch kann eine jewei- 
lige Komponente beispielsweise abhangig von sich Sndem- 
den extemen Bedingungen, wie der verfugbaren Obertra- 
gungskapazitat der Kommunikationsstrecke des Netzwerks, 
fUr gewisse Zeiten in einem und fiir andere Zeiten in einem 
anderen Systemteil plaziert werden, Fiir eine solche \ferla- 
gerung eignen sich insbesondere diejenigen Komponenten, 
die nicht eng mit fahrzeugseitigen Hardware-Gerateeinhei- 
ten zusapimenhSngen. 

Bei einem nach Anspruch 5 weitergebildeten System er- 
folgt die Kommunikation zwischen anwendungsbezogenen 
Komponenten direkt, wobei dann die Komponente die 
Schnittstellen derjenigen Komponenten kennen muB, die sie 
verwendet, oder iiber eine jeweilige, gemeinsam genutzte 
Datenhaltungs-Komponente, in welche die beteiligten An- 
wendungs-Komponenten neue Informationen einschreiben 
und dort neu eingeschriebene Informationen von anderen 
beteiligten Komponenten auslesen konnen. In diesem Fall 
brauchen die Anwendungs- Komponenten die Schnittstellen 
der anderen Komponenten nicht zu kennen, es muB jedoch 
vereinbart werden, welche Inhalte in die Datenhaltungs- 
Komponente geschrieben werden. 

Vorteilhafte Ausfuhrungsformen der Erfindung sind in 
den Zeichnungen dacgestellt und werden nachfolgend be- 
schrieben. Hierbei zeigen: 

Fig. 1 eine schematische DarsteUung eines verteilten 
Fahrzeuginformationsverarbeitungs- und Fahrzeugsteuersy- 
stems mit fahrzeugseitigem und fahrzeugextemen, mitein- 
ander vemetzten Systemteilen, 

Fig, 2 ein schematisches Blockdiagramm der Umgebung 
einer Port-Manager-Komp(»iente im fahrzeugseitigen Sy- 
stemteil von Fig. 1, 

Fig. 3 ein schematisches Blockdiagramm der Umgebung 
einer Location-Manager-Komponente im System von Fig. 
1, 

Fig. 4 ein schematisches Blockdiagramm der Umgebung 
einer Prasentations-Manager-Komponente im System von 
Fig.l, 

Fig. 5 ein schematisches Blockdiagramm der prinzipiel- 
len, komponentenbasierten Architektur des Systems von 
Fig.l, 

Fig. 6 ein schematisches Blockdiagramm der funktions- 
orientierten hierarchischen Aufteilung der Komponenten im 
System von Fig. 1 , 

Fig. 7 ein schematisches Blockdiagramm zur Veran- 
schaulichung der dynamischen Verlagerung einer Kompo- 
nente zwischen Systemteilen von Fig. 1, 

Fig, 8a und 8b schematische Blockdiagramme zur Veran- 
schaulichung der Komponenten verlagerung am Beispiel ei- 
ner Sprachbedien-Anwendung, 

Fig. 9 ein schematisches Blockdiagramm eines Navigati- 
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ons-Teilsystems des Systems von Fig. 1 auf Diensteschnitt- 

slellen-Basis, 

Fig. 10 ein schematisches Blockdiagramm zur Veran- 
schaulichung einer Dienstinteraktion im System von Fig. 1 
Uber eine Datenhaltungs-Komponente und 

Fig. 11 ein schematisches Blockdiagranmi zur Vi^^- 
schaulichung des Aufhifs einer Komponentenmethode. 

Fig. 1 zeigt schematisch ein verteiltes Fahrzeuginformati- 
onsverarbeitungs- und Fahrzeugsteuersystem, das eine 
Mehrzahl von raumlich getieimten Systemteikn la, 2a, 3a 
umfaBt, die aktive Netzknoten eines DatenQbertragungs- 
netzwerks 4, wie z. B. das Internet, bilden und uber dieses 
tniteinander kommunizieren. Ein erster Systemteil befindet 
sich im Fahrzeug 1 selbst, das einen "Mobile-Host" des 
Netzwerks 4 darstellt. Ein zweiter, stationaier Systemteil 2a 
befindet sich in einem Service-Provider 2, wahrend sich ein 
dritter Systemteil 3a in einem Hochleistungs-Service-Center 
3 befindet. Weitere Fahrzeuge konnen in gleicher Weise ak- 
tive Netatooten bilden, die auf Dienste des Service-Provi- 
ders 2 und des Hochleistungs-Service-Centers 3 zugreifen 
konnen, wobei in nicht gezeigter auch jeweils eine Mehrzahl 
der beiden letztgenannten Dienstanbieter im Datennetz 4 
vorhanden sein kann. Diese fahrzeugextemen Dienstanbie- 
ter 2, 3 dienen iiblicherweise vor allem dazu, Dienste fiir das 
Fahrzeug 1 auszufuhren, die eine relativ hohe Rechenkapa- 
zitSt erfordem, wie sie im Fahrzeug 1 nicht ohne weiteies 
verfiigbar ist, z. B. aufwendige Navigationsdienste wie ver- 
kehrslageabhangige Routenfindung. Das Fahrzeug 1 hat 
ebenso wie die stationaien Dienstanbieter 2, 3 eine Netz- 
weriddentitat, mit dem es im Netzwerk 4 bekannt isL In den 
Funktionsbldcken der diei gezeigten Netzknoten 1, 2, 3 ist 
schematisch angedeutet, daB der dort jeweils implementierte 
Systemteil la, 2a, 3a einen komponentenbasierten Aufbau 
besitzt, worauf unten nSher eingegangra wird. Ftir den vor- 
liegenden Anwendungsfall von Fahrzeugsystemen erscheint 
hierfOr von den oben genannten drei herkdmmlichen Tech- 
nologien, die verteilte Komponentensysteme unterstutzen, 
namlich RMI, CORBA und DCOM, die Java-RMI Techno- 
logic besonders geeignet, da sie plattformunabhSngig und 
mit relativ geringem Aufwand handhabbar ist. 

Die Komponenten, aus denen die Systemteile 1, 2, 3 und 
damit das System insgesamt aufgebaut ist, beinhalten je- 
weils zwei Schnittstellen, und zwar eine Funktionsaufhif- 
oder Remote-Schnittstelle, fiber welche die eigentliche 
Funktion der betreflfenden Komponente, d. h. ihr Dienst, 
von einer anderen Komponente desselben Systemteils oder 
auch von einem entfemten Netzknoten aus aufgerufen wer- 
den kann, und eine Konfigurations-Schnittstelle, die zur va- 
riablen, situationsangepafiten Konfigurierung der Kompo- 
nente dient. tJber diese Konfigurations-Schnittstelle kann 
die Komponente variabel in verschiedene Umgebungen des 
Systems "hineinkonfiguriert" werden, und vorhandene 
Komponenten konnen fiber diese Schnittstelle von der neu 
plazierten Komponente in Kennmis gesetzt weiden. Dies er- 
moglicht ein einfaches Einbringen und Verlagem einer 
Komponente auch nach der Systemgenerierung zur System- 
laufzeit, selbst bei geSnderten Randbedingungen des Sy- 
stems. In diesem Fall mfissen die neu ^ngebrachten und un- 
ter Umstanden auch die schon bisher vorhandenen Kompo- 
nenten des Systems aufeinander angepaBt werden. Dies 
kann z.B. bedeuten, daB die Adressen der Komponenten 
untereinander bekanntgemacht werden mussen, wozu die 
Komponenten eine eigene "Home-Page" anbieten, uber wel- 
che die notwendigen Modifikationen vorgenommen werden 
konnen, VorUegend ist zur Durchfuhrung dieser Konfigura- 
tlonsaufgabe eine spezielle Konfigurationsmanagereinheit 
vorgesehen. Diese weiB, welche Komponenten momentan 
im System vorhanden sind und hat fiber die Konfigurations- 



Schnittstelle Zugriff auf die einzelnen Komponenten zur 
Modifikation ihrer Konfiguration. 

Der Systemteil 2a des Service-Providers 2 enthalt primar 
Anwendungs-Komponenten zur Ausfiihrung von Diensten 
5 fahizeugbezogener Funktionalitat, wahrend der Systemteil 
3a im Hochleistungs-Service-Center 3 pnmai Anwendungs- 
Support-Komponenten enthSlt, die Hochleistungsrechenka- 
pazitMten bendtigen. Im fahrzeugseitigen Systemteil la sind 
neben Anwendungs-Komponenten, wel,che die eigentllchen 

10 Dienstanwendungen reprasentieien, vor allem auch "gerate- 
nahe" Komponenten vorhanden, die zur Steuerung von im 
Fahrzeug 1 verbauten Hardware-Gerateeinheiten dienen, 
wie z. B, eine Prasentations-Manager- Komponente 19, die 
auf eine optische Anzeige 24 und einen Lautsprecher 26 zu- 

15 greift. Zusatzlich dienen Kommunikations-Manager-Kom- 
ponenten der Abwicklung von Datenkonununikationsvor- 
gangen zwischen den Systemteilen la, 2a, 3a fiber das Netz- 
werk 4. Der Gesamtheit der Komponenten des jeweifigen 
Systemteils la, 2a, 3a ist ein zugehoriger Komponenlen-La- 

20 der ("Badewanne") oder Komponenten-Server lb, 2b, 3b 
zugeordnet. Als ein solcher Komponenten-Lader eignet sich 
z. B. der in der Programmiersprache Java implementierte 
ChaiServer der Firma Hewlett-Packard, der das Laden der 
Komponenten sowie das Routing von Methodenaufirufen an 

25 die entsprechenden Komponenten unterstutzt; fiir weitere 
Details siehe die Firmeninformationen Hewlett-Packard 
"HP ChaiServen An Overview" auf der Intemet-Seite 
"http://www.chai.hp.com/emso/pdf/chaii5erverwp.pdr und 
"HP Application Serv^" auf Intouet-Seite 

30 "httpV/www.hpconnecQnnectcom/embedded/vm/ 
sweb.htm**. 

In den F^. 2 bis 4 sind diei Bdspiele fiir Komponenten 
des Fahizeuginformationsverarbeitungs- imd Fahrzeugsteu- 
ersystems veranschaiilicht Fig* 2 zeigt eine Port-Manager- 

3S Komponente 5 in ihror Systemumgebung, z. B. innerhalb 
des im Fahrzeug 1 befindlichen Systemteils. Die Port-Mana- 
ger-Komponente 5 gehort zu einer Gruppe von hardwareun- 
terstutzenden Interface-Komponenten, die eng im Zusam- 
menhang mit fahrzeugseitigen Hardware-Gerateeinheiten 

40 stehende Funktionen ausfiihren, z. B. Treiberfunktionen. 
Die Port-Manager-Komponente 5 ermbgUcht den Zugriff 
auf eine s^elle Schnittstelle 6 der Maschine, hier dem 
Fahrzeug 1, auf der sie ablauft. Dabei werden die ZugriflTs- 
methoden so zur Verfugung gestellt, daB auf sie von jeder 

45 berechtigten Remote-Komponente zugegriffen werdra 
kann. Die Port-Manager-Komponente 5 kennt hierzu die 
Schnittstellen des Systems und verwaltet unter anderem die 
Zuordnung der Schnittstellen und der angeschlossenen Ge- 
rate. Sie ist auBerdem verantwortlich fur die Regelung von 

50 konkurrierenden Aufhifen anderer Komponenten auf die 
Ports. tJber ihre Remote-Schnittstelle 5a erlaubt die Port- 
Manager-Komponente 5 einen Zugriff auf die SchnittsteUen 
des Systems von jeder beliebigen Stelle im Netzwerk, wie 
z. B. von zwei explizit gezeigten Anwendungen 7a, 7b. Zu- 

SS slitzlich ist die Konfigurations-Schnittstelle 5a der Port-Ma- 
nager-Komponente 5 schematisch gezeigt Die Port-Mana- 
ger-Komponente 5 hat keine Information fiber den semanti- 
schen Inhalt der Informationen, die Uber sie abgerufen oder 
geschrieben wird. In der gew^Uilten Java-Implementierung 

60 ist daher die Java- Virtual-Machine (JVM) 8 durch zusStz- 
fich gebildete Klassen 9, d. h. "Port-Classes", in die Lage 
versetzt, einen physikalischen Zugriff auf die serielle 
Schnittstelle 6 zu erlauben. 

Die in Fig. 3 in ihrer Einbettung in die architektonische 

65 Systemumgebung gezeigte Location-Manager- Komponente 
oder Positions-Manager-Komponente 10 hat die Funktion, 
Positionsinformalon zu sammeln und diese dann aggregiert 
ais Ortsinformationsdienst anzubieten. Mogliche Informati- 
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onsquellen sind z. B. ein GPS-Empfanger 11 und Koppelna- 
vigalionssensorcn 12, 13, wic KoinpaB und Raduindre- 
hungszahler. Die Location-Manager-Komponente 10 greift 
dazu auf entsprechende Interface- Komponen ten zu, wie den 
oben envahnten Port-Manager 5 und eine CAN-Manager- 
Komponente 14, die ihrerseits iiber die JVM^etriebssy- 
stems-Schicht 15 auf eine CAN-Schnittstelle 16 zugreift. 

Mit einem Auslagerungspfeil 17 ist eine Auslagerungs- 
mdglichkeit veranschaulicht, wonach die Location- Mana- 
ger- Komponente 10 nicht zwingend auf derselben Ma- 
schine, z. B. dem Falirzeug 1, laufen muB wie die Interface- 
Komponenten 5, 14, auf die sie zugreift, sondern eine ex- 
teme, ausgelagertc Komponente 10' bilden kann, die sich in 
einem anderen Systemteil befindet. Ob eine solche Auslage- 
rung zweckmSfiig ist, hangt von den jeweils momentanen 
Randbedingungen, insbesondere dem Aufwand und den Ko- 
sten ftir die Datenkommunikation zwischen den Systemtei- 
ien ab. Im Obrigen weist auch die Positions-Manager-Kom- 
ponente 10 wie alle Komponenten des erfindungsgemaBen 
Systems wiederum eine Remote-Schnittstelle 10a zur Kom- 
munikation mit anderen Diensten 18a, 18b und eine Konfi- 
gurations-Schnittstelle 10b auf. 

Fig. 4 zeigt wiederum eingebettet in ihre Systemumge- 
bung eine Prasentations-Manager- Komponente 18 mit Re- 
mote-chnittstelie 18a zum Funktionsabruf durch andere An- 
wendungen 20a, 20b und Konfigurations-Schnittstelle 19b. 
Die Prasentations-Manager-Komponente 19 ist fiir die Wie- 
deigabe von Information der Anwendungen 20a, 20b zu- 
standig und gibt die Information in Abhangigkeit von aus- 
tauschbaren Strategien an den Benutzer weiter. Diese Strate- 
gien konnen beispielsweise beinhalten, daB wahrend der 
Fahrt Information nur iiber Sprachausgabe stattfindet und 
eine optische Anzeige (Display) nur im Stand aktiviert wird. 
Durch solche Strategien lassen sich erforderliche Sicher- 
heitsvorkehrungen in das System einbringen, damit der oder 
die Fahrzeuginsassen nicht von ihrer eigentlichen Aufgabe 
abgelenkt werden. Der Prasentations-Manager hat zur Erful- 
lung seiner Aufgabe uber jeweilige Schnittstellen-Manager- 
Komponenten 21, 22 und das Betriebssystem 15 nebst ent- 
sprechenden Schnittstellen Zugiiff auf Benutzerschnittstel- 
len-Komponenten des Fahrzeugs, wie "Text-to-Speech"-, 
"Speech-tchlbxf-Gerate 23, optische Anzcigen 24 und 
"Touch-Screen"- bzw. "Poiniing"-Gerate. DiePrasentations- 
Manager-Komponente 19 kooperiert eng mit dem Konfigu- 
rationsmanagement des Systems, da sie Informationen dar- 
Qber benStigt, welche Aus- und Eingabeger^te im Fahrzeug 
vorhanden sind. AuBerdem ist sie in der Lage, konkuirie- 
rende Ausgabeanforderungen verschiedener Anwendungen 
geeignet aufzulosen, vergleichbar einem "Window-Mana- 
ger". 

Wie gesagt, ist die Architektur des verteilten Fahrzeugin- 
formationsverarbeitungs- und Fahrzeugsteuersystems voll- 
stSndig aus Komponenten aufgebaut, wobei in den Figuren 
die Komponenten zur einfacheren Identifizierung jeweils 
mit einem kleinen Dreieck in der oberen linken Ecke ihres 
Funktionsblocks markierl sind. Fig. 5 zeigt die prinzipielle 
Architektur des Systems, bestehend aus einer Anzahl n von 
Komponenten Ki, . . . Kq, denen ein Komponenten-Server 
KS zugeordnet ist und die iiber das jeweilige Beunebssystem 
BS auf eine Anzahl m extemer Gerate Gj, . , . On, Zugriff 
haben. Aus dieser Software-Sichtweise besteht das System 
folglich aus einer Menge von miteinander kommunizieren- 
den Komponenten Ki, . . . Kn, wobei es auf dieser Ebene 
keine Hierarchien zwischen den einzelnen Komponenten 
Ki, ...K„ gibt. 

Die Kommunikation zwischen den Systemobjekten ba- 
sicrt auf hcrkommlichcn Vorgchcnsweiscn, wie "Rcmotc- 
Procedure-Call" (RPC) bzw, dessen Java- Version, der "Re- 
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mote-Method- In vocation" (RMI). Methoden einer Kompo- 
nente, die von einer anderen Komponente aufgerufen wer- 
den sollen, werden in einer Interface-Datei beschrieben, ver- 
gleichbar mit der "Interface-Description-Language" (IDL) 
5 von CORBA, Aus dieser Datei werden dann die notigen 
"Stubs" generiert, die zu einer Komponente hinzugebunden 
werden. Zur Adressierung der Methoden wird der "Uni- 
form-Resource-Lxx;ater" (URL) verwendet, mil dem dieje- 
nige Machine adressiert wird, auf der die angesprochene 
10 Komponente lauft, und auf dem des weitcren die Kompo- 
nente selbst und die gewunschte Methode mit Aigumenten 
angegeben werden kann. Durch die UAL- Adressierung wird 
Qrtstransparenz, d. h. Positionierungsunabhangigkeit der 
Komponenten, erreicht, da die Aufldsung der Maschinen- 
15 adresse unabhangig von der Client-Instanz erfolgt, z. B. 
uber einen "Domain-Name-Service" (DNS). 

Fig. 6 zeigt eine funktionsoriente Anordnung der Kompo- 
nenten des Systems. In dieser Darstellung ist eine dreistufige 
Hierarchic der Komponenten vorgesehen, bei der eine ober- 

20 ste Schicht aus eigentlichen Anwendungen, eine mitdere 
Schicht aus Anwendungsunterstiitzungsfunktionen und eine 
untere Schicht aus Schnittstellensteuerungsfunktionen be- 
steht. Die Komponenten der obersten Schicht bilden die ei- 
gentlichen Anwendungen oder Dienste, d. h. Anwendungs- 

25 Komponenten AKi, AK2, AK3, . . . Beispielhaft sind ein 
Nachrichtenvorleser und eine Navigationskomponente ge- 
zeigt. Zur ErfuUung ihrer Aufgaben greifen die Anwen- 
dungs- Komponenten AKi, AK2, . . . auf die mittlere Schicht 
von anwendungsunterstutzenden Komponenten UKi, UK2, 

30 UK3, . . . zu, die auch als Aggregations-Komponenten be- 
zeichnet werden konnen, da sie Rohdaten, die aus verschie- 
denen Quellen im Fahrzeug und aus der fahrzeugextemen 
Infrastruktur des Netzes kommen konnen, geeignet aggre- 
gieren. Beispiele fiir solche Anwendungsunterstiitzungs- 

35 komponenten sind die oben erlauterten Location-Manager- 
und Prasentations-Manager-Komponenten sowie die Kom- 
munikatons-Manager-Komponente. Diese anwendungsun- 
terstutzenden Komponenten UKi, UK2, UK3, . . . greifen ih- 
rerseits auf die Interface-Komponenten DCi, IK2, IK3, der 

40 unteren Schicht zu, die eng an fahrzeugseitige Hardware- 
Gerateeinheiten angebundene Komponenten darstellen, wie 
dcT oben edauterte (serielle) Port-Manager, eine CAN-Ma- 
nager- und eine Anzeige-Manager-Komponente. 

Allen Komponenten ist der Komponenten-Lader KL zu- 

45 geordnet, und die Kommunikation mit extemen Geraten, 
z. B. einer optischen Anzeige 24, ein^* Audio-Schnittslelle 
27, Modems 28, einem GPS-Empfanger 29 und einem DVD 
30 erfolgt uber die JVM/Betriebssysiem-Schicht 15. Auf 
diese Weise unterstiitzt das System exteme Gerale, die der 

50 Benutzerschnittstelle zuzuordnen sind, aber auch Gerate, die 
der Benutzer neu in das System einbringt. Wenn for nachge- 
brachte exteme Gerate keine Interface-Komponenten vor- 
handen sind, sind sie nachtraglich zu laden. Den erwahnten, 
ftinktionsorientiert in drei Schichten gegliederten Kompo- 

55 nenten ist gemeinsam eine Konfigurations-Manager-Kom- 
ponente KM zugeordnet, mit deren Hilfe die Komponenten 
dynamisch zwischen den verschiedenen Systemteilen des 
Systems verlagert werden konnen. 

Ein weiterer Anwendungsfall ist das Nachladen von 

60 Komponenten insbesondere der obersten Schicht, d. h. von 
Anwendungs-Komponenten. Das mit Hilfe der vorliegen- 
den Plattform mogliche Nachladen solcher Anwendungs- 
Komponenten behebt die Schwierigkeit, daB fUr Fahrzeug- 
systeme im Moment ihrer Projektierung haufig nicht genau 

65 bekannt ist, welche Dienste fiir den Kunden iiber die ge- 
samte Lebensdauer des Fahrzeugs hinweg von Interesse sein 
werden. Insbesondere konunen hier auch Dienste in Bc- 
tracht, die fUr ihre Nutzung notwendige Software vor der 
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Dienstausfiihrung von einem fahrzeugextemen Systemteil 
in das Fahrzcug Laden. Das zentrale Elemenl fur das Nachla- 
den von Komponenten ist der Komponenten-Lader KL. Er 
ermoglicht sowohl das Einbringen neuer Komponenten in 
den betreffenden Systemteil wie auch das Auslagem nicht 
mehr benotigter Komponenten, 

Die Fahigkeit zum dynamischen Veriagem von Kompo- 
nenten ist bei Fahrzeugsystemen insbesondere aufgrund der 
begrenzten fahrzeugseitigen Rechenkapazilaten von Inter- 
esse. So ist es zum einen wunschenswert, nur eine relativ ge- 
ringe Rechenkapazitat im Fahrzeug vorhalten zu miissen 
und die Haupdast der Berechnungen in der fahrzeugexter- 
nen Infrastruktur des Systems zu erledigen, zum anderen 
sollen die Kommunikationskosten zur Ankopplung des fahr- 
zeugseitigen Systemteils an das Netz moglichst gering ge- 
halten werden. Nun sind jedoch die Kommunikationskosten 
je nach Land oder Region zum Tell betrachtlich verschie- 
den. Beriicksichdgt man die Mobilit^t von Fahrzeugen, so 
kann sich diese Randbedingung sogar wahrend einer Fahrt 
andem. V/vcd zudem noch die absolute Vorfiigbaikeit eines 
Kommunikationsdienstes in das Kostenmodell aufgenom- 
men, so ei:gibt sich ein Optimierungsproblent, das mit einer 
dynamischen Verschiebbarkeit von Komponenten zwischen 
den Systemteilen deudich besser losbar ist als mit einer star- 
ren Struktm* und V^teilung der Komponenten. Der Konfi- 
guradons-Manager KM dient nun dazu, eine jeweilige verla- 
gerte Komponente in ibre neue Umgebung "hineinzukonfi- 
gurieren" und die bereits vorhandenen Komponenten Uber 
die neu in den betreffenden Systemteil hinzugekommene 
Komponente zu "informieren", d. h. deren Konfiguration 
daran anzupassen. Zu diesem Zweck hat der Konfigurations- 
Manager KM uber die Konfigurations-Schnittstellen ZugrifF 
auf die einzelnen Komponenten des betreffenden System- 
teils. Der Konfigurations-Manager KM weiB, welche Kom- 
ponenten im System sind, Uberpriift deren Konsistenz und 
nimmt dann die geeigneten modifizierenden Konfigurati- 
onszugriffe auf die einzelnen Komponenten vor. 

Fig* 7 zeigt die Fahigkeit zum dynamischen Veriagem ei- 
ner Komponente zwischen einem Fahrzeug 31 einerseits 
und fahrzeugextemer Systeminfrastruktur 32 andererseits 
am Beispiel einer Service-Support-Komponente 33 anhand 
von drei unterschiedlichen Szenarien, die eine solche Kom- 
ponentenverlagerung wiinschenswert machen, siehe hierzu 
auch den Zeitschriftenaufsatz S. Hild und P. Robinson, "Mo- 
bilizing Applications", IEEE Phonal Communications, 4, 
Nr. 5, 1997, Seite 26. Ausgegangen wird hierbei von einem 
erweiterten Client/Server-ModelU bei dem zwischen einer 
PrasentationS'Manager-Komponente 34 im Fahrzeug 31 als 
Client und einer Server-Komponente 35 auf der In&astruk- 
turseite noch als Server die Service-Support-Komponente 
33 zwischengeschaltet ist, die in reduziertem MaB gewisse 
Server-Funktionen statt der in&astrukturseitigen Server- 
Komponente 35 ausfUhren kann. 

Im Fall hoher Kommunikationskosten zwischen Fahr- 
zeug 31 und Infrastruktur 32 wird die im obersten Teilbild 
von Fig, 7 dargestellte Losung gewahll, bei der die Service- 
Support-Komponente 33 im Fahrzeug 31 pxjsitioniert ist, so 
daB sie ihre Kommunikation mit dem Prasentations-Mana- 
ger 34 fahrzeugintem abwickeln kann und ein hoher Anteil 
der Berechnungen im Fahrzeug 31 durchgefuhrt wird, was 
die Kommunikation mit der Infrastruktur 32 minimal halt 
Oder zeitweise ganz vermeidet. In diesem Fall bildet das 
Fahrzeug einen "Thick Mobile Host", der eine reduzierte 
Version der infrastrukturseitigen Servicer- Komponente 35 
in Form der Service-Support-Komponente 33 enthSlt. 

Ist der Aufwand fiir die Kommunikation zwischen Fahr- 
zeug 31 und Infrastruktur 32 hingegen veigleichsweise ge- 
ring, ist es giinstig, die in Fig. 7 im mitderen Tsilbild ge- 
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zeigte Losung zu wahlen, bei der die Service-Support-Kom- 
ponente 33 in der Infrastruktur 32 angeordnet ist und dort 
die Vorteile der gr5Beren Rechenkapazitat und die Verfiig- 
barkeit weiterer, im Datennetz befindlicher Ressourcen, wie 
s z. B. aktuelle Verkehrsdaten, nutzen kann. In diesem Fall 
bildet das Fahrzeug einen "Thin Mobile Host". 

Die dynamische Verlagerung von Komponenten, wie hier 
der Service-Support-Komponente 33, dient nun dazu, eine 
bleibende Beschrankung auf die eine oder die andere dieser 
10 beiden erwahnten Losungen zu vermeiden und stattdessen 
in der Lage zu sein, zur Systemlaufzeit die Komponenten je 
nach Randbedingungen zwischen den Systemteilen, hier 
zwischen der Infrastruktur 32 und dem Fahrzeug 31, hin und 
her zu verschieben, d. h. die Service-Support-Komponente 
15 33 wahlweise in das Fahrzeug 31 oder in die Infrastruktur 32 
zu veriagem, wie mit dem unteren Teilbild von Fig. 7 ange- 
deutet ist. Das Fahrzeug 31 bildet dann einen "komponai- 
tenbasierten Host", in den wahlweise Komponenten aus der 
Infrastruktur 32 geladen bzw. aus dem Komponenten in die 
20 Infrastruktur 32 ausgelagert werden konnen. 

Diese wesendiche Eigenschaft des vorliegenden Systems 
ist konkreter am Bdispiel einer Sprachbedien- Anwendung in 
den Fig. 8a und 8b veranschaulicht Fig. 8a zeigt ein Spradi- 
bediensystem-Steueigei^ 36, das nut einem Komponenten- 
25 system, d. h. mit einem Komponenten-Lader, ausgeriistet 
isL Dber das SteuergerSt 36 erfolgt ein Zugriff auf die not- 
wendige Hardware, d. h, einen Lautsprecher 37 und cm Mi- 
krofon 38. Auf diesem Systemteil laufen folgende Kompo- 
nenten. Eine hardwarebezogene Komponente 39 dient dem 
30 Zugrifif auf das Mikrofon 38 und den Lautsprecher 37. Eine 
erste anwendungsunterstutzende Komponente 40 enthSlt 
das fiir die gewiinschte Sprachbedienung erfcHtlerliche Vo- 
kabular, z. B. in Deutsch. Eine zweite anwendungsunterstut- 
zende Komponente 41 bildet einen Spracherkenner und 
35 Synthesizer, der die notwendige Spracherkennung und 
Sprachsynthese bewerkstelligt. Eine Anwendungskompo- 
nente in Form eines Nachrichtenvorlesers 42 dient zur 
Steuerung der Applikation. 

Ausgehend von diesem Sprachbedien-Systemteil besteht 
40 ein mogliches Szenario darin, die Vokabular-Komponente 
40 zwecks Landeranpassung des Systems und damit des 
Fahrzeugs gegen eine solche mit einer anderen Sprache aus- 
zutauschen. Ein anderes Szenario kann im Fall eines Miet- 
fabrzeugs darin bestehen, eine Anpassung an die jeweils von 
45 einem Kunden gewiinschte Sprache dadurch zu realisieren, 
daB sich die Vokabular-Komponente mit der jeweiligen 
Sprache uber ein Menu vom Kunden auswahlen laBt, wor- 
aufhin die betreffende Komponente nachgeladra wild. Nach 
Rackgabe des Mietfahrzeugs wird die nachgeladene Kom- 
50 ponente dann wieder entfemt. 

Hn komplexerer Fall ^ner Komponentenverschiebung 
fur den Systemteil von Fig* 8a ist in Fig. 8b daigestellt Die- 
ser Fall betrifft eine Auslagerung moglichst vieler Kompo- 
n&at&n des Sprachbedien-Systemteils vom Fahrzeug 36 in 
55 fahrzeugexteme Systemteile, d. h. in die fahrzeugexteme In- 
frastruktur 43 des Gesamtsystems. Speziell konnen dutch 
die Fahigkeit des vorliegenden Systems zur dynamischen 
Komponentenverlagerung die Anwendungs-Komponente 
42 und die beiden anwendungsunterstutzenden Komponen- 
60 ten 40, 41 in die Infrastruktur 43 verlegt werden, wo sie auf- 
grund der hoheren Rechnerlei stung eflftzienter arbeiten kon- 
nen. Im Fahrzeug 36 verbleibl die fahrzeugeratenahe Inter- 
face-Komponente 40. Die Daten werden uber die fahrzeug- 
seitig verbliebene Schnittstellen-Komponente 40 und eine 
65 drahdose Verbindung 44 zwischen Fahrzeug 36 und fahr- 
zeugextemer Infrastruktur 43 iibertragen. Abhangig von der 
vorhandenen drahUosen Kommunikation, insbesondere ih- 
rer VerfUgbarkeit und ihren Kosten, kann auf diese Weise 
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ein optimaler KompromiB fiir die Verteilung der Kompo 
ncntcn 39 bis 42 dcs Sprdchbedicnsystciiis zwischcn Fahr- 
zeug 36 und fahrzeugextemer Tnfrastruktur 43 gewahlt wer- 
den. 

Je nach Anforderungen an fahrzeugbezogene Dienste, 
wie Telematik-Dienste, ist beim vorliegenden verteilten 
Pahrzeuginformationsverarbeitungs- und Pahrzeugsteuersy- 
stem eine bestimmte Basismenge von Komponenten in 
Fahrzeugen und in der Infrastruktur vorhanden, die Dienste 
wie bcispielswcise "Zeit", "Ort/Position" cxler "Map-Mal- 
ching" anbieten. Diese Basisdienste konnen dann von meh- 
reren anderen Diensten verwendet werden. So kann bci- 
spielswcise die Ortsinfomiation sowohl von cineiri Naviga- 
tionsdienst genutzt wie auch von einem Pannenhilfsdienst 
dazu verwendet werden, die aktuelie Fahrzeugposition an 
die Pannenhelfer weiterzugeben. Dienstanbieter miissen sei- 
che Basisteile des Systems nicht wiederhoU cntwerfen, son- 
dem konnen auf die vorhandenen Basiskomponenten aufset- 
zen. Mit Hilfe der vorliegenden komponentenbasierten Sy- 
stemarchitektur konnen neue Dienste auf der Basis existie- 
render Komponenten auf zwei von der Systemarchitektur 
unterstatzte Arten realisiert werden, und zwar nach einem 
schnittstellenbasierten oder ^nem ereignisgesteuerten 
Dienstmodell. 

Beim schnittstellenbasimen Modell wird davon ausge- 
gangen, daB die existierenden Komponenten und ihre unter 
Umstanden umfangreichen Dienste-Schnittstellen mit alien 
notwendigen Methoden bekannt sind. Ein neuer Dienst kann 
dann einfach durch die Verwendung der existierenden Funk- 
tionen erscellt werden. Voraussetzung ist, daB das notwen- 
dige Wissen Uber die prinzipielle Existenz der Komponente 
und aber deren genauen Dienstumfang erhalten wird. 

Fig. 9 zeigt ein Navigations-Teilsystem, das auf einem 
solchen schnittstellenbasierten Modell aufgebaut ist. Dabei 
greift eine Komponente "Navigationsdienst" 45 auf die 
Dienste anderer Komponenten zu, wie auf eine "Mapping"- 
Komponenle 46, eine "Routing "-Komponente 47, eine Rad- 
drehzahlerfassungs-Komponente 48, eine Prasentations- 
Manager- Komponente 49 etc., um ihren Dienst gegeniiber 
dem Anwender zu erbringen. Bei der Programmiening der 
Navigationsdienst-Komponente 45 miissen die Schnittstel- 
len der verwendeten Komponenten bekannt sein. 

Fig, 10 zeigt den Fall eines ereignisgesteuerten Modells, 
das durch Verwenden einer "Shared-Space"-Komponente 50 
realisiert ist, die einen server-basierten, von mehreren betei- 
ligten Komponenten gemeinsam genutzten Datenspeicher 
darstellt, in den die beteiligten Komponenten bestimmte in- 
teiessierende Werte/Objekte einschreiben konnen, wie dies 
in Fig. 10 fiir eine Kalenderanwendungskomponente 51 und 
eine weitere Anwendungskomponente 52 dargestellt ist 
Des weiteren konnen sich die beteiligten Komponenten bei 
dieser "Shared-Space"-Komponente 50, die somit als eine 
Datenhaltungs-Komponente fiingiert, registrieren lassen, 
um im Fall eines neu auftretenden Wertes/Objektes, der fiir 
sie relevant ist, informiert zu werden, als sogenannte "event 
triggered notification*' bezeichnet. 

AnsMtze dieser Art verschieben das oben angesprochene 
Problem des A^ssens Uber die Existenz von Komponenten 
auf eine hohere Ebene, indem die Kommunikation zwischen 
Komponenten immer Ober die "Share-Space"-Komponente 
50 stattfindet, die mit einer sehr kleinen APT realisiert wer- 
den kann und jeder Komponente bekannt ist. Die Kompo- 
nenten miissen sich lediglich iiber die Inhalte einigen, die in 
die "Shared-Space'-Komponente 50 geschrieben werden. 
Solche Ansalze sind z. B. unter den Bezeichnungen "Linda 
Space", siehe Internet-Seite '*http://www,cs.y ale.edu/ 
HTMLA7^LE/C:S/Linda/linda.hLna" und "Java Spaces", 
Sun Microsystems, Internet- Seite http://java.sun.com/pro- 
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ducts/javaspaces/specs" in der allgemeinen EDV gelaufig. 

Iin Bcispiel von Fig. 10 liefert die Kalender-Anwcndung 
51 Neueintrage 53 in die Datenhaltungs-Komponente 50. 
Interessiert sich eine andere Anwendung 52 fiir derartige 
5 Daten, erhalt sie die betreffende Dateninformation 54 von 
der Datenhaltungs-Komponente 50, wenn sie bei ihr hierfUr 
registriert ist. Die andere Anwendung 52 kann daraus neue 
Daten 55 generieren und den iibrigen Komponenten zur Ver- 
fiigung stellen, indem sie diese in die Datenhaltungs-Kom- 
10 poncnte 50 schreibL. Inlcressicrt sich die Kalender-Anwen- 
dung 52 fiir diese neuen Daten 55, kann sie die betreffende 
Information 56 von der Datenhaltungs-Komponente 50 er- 
halten, woraufhin der Datenaustauschkreislauf wieder von 
vome beginnen kann. 
15 Der Vorteil dieses Modells besteht in der voneinander un- 
abhangigen PVogrammierung der Komponenten und dem 
geringen Umfang der "Shared-Space "-API. AuBerdem k6n- 
nen neue Komponenten problemlos in das System integriert 
werden und sofort aktiv zur Erbringung von Mehrwertdien- 
20 sten beitragen. Applikationen miissen hierzu "kooperativ" 
geschrieben werden, d. h. so, daB sie relevante Infc»-mation 
auch tats^hlich in die "Shared-Space"-Komponente schrei- 
ben. In der "Shared-Space"-Komponente sind geeignete 
Mechanismen, wie 2^tQberwachung, IVansaktionsmodelle 
25 etc., impiementiert, die das Auftreten oszillierender Effekte 
zwischen-Komponenten beim wechselseitigen Einschreiben 
neuer Werte in die "Shared-Space"-Komponente unterbin- 
den. Vorteilhaft kann eine kombinierte Realisierung von 
zum Teil schnittstellenbasierter und zum Teil ereignisge- 
30 steuerter Modellierung in Abhangigkeit von den jeweiligen 
Anwendungen sein. So ist z. B. bei der Verarbeitung eines 
Motordrehzahlwertes, der standige in Abst^den von weni- 
gen MiUisekunden zur Verfugung steht, ein ereignisgesteu- 
ertes ModeU, bei dem jeder neue Drehzahlwert in die "Sha- 
35 red-Space"-Komponente geschrieben und aUe potentiellen 
Abnehmerkomponenten dariiber benachrichtigt werden, 
wenig sinnvoll, so daB hierfiir eine schnittstellenbasierte 
Modellierung zu favorisieren ist. 

Eine plattformunabhangige Realisierung des vorliegen- 
40 den verteilten Fahrzeuginformationsverarbeitungs- und 
Fahrzeugsteuersystems ist, wie schon erwahnt, z. B. durch 
Wahl der Entwicklungs- und Implementierungsumgebung 
"Java" moglich, da diese bereits an vielen Stellen eine ob- 
jektorientierte Implementiening von Komponenten direkt 
45 unterstiitzt, wobei als Komponenten-Lad^, wie ebenfalls 
oben erwahnt, z. B. der in Java implementierte ChaiServer 
von Hewlett-Packard genutzt werden kann. Um einen Zu- 
griff auf die Systemhardware zu ermoglichen, der von Java 
nicht standardm^ig voigesehen ist, werden zusiitzliche 
so Klassen in das System gebracht, die ebenfalls Uber das Sy- 
stemkonfigurationsmanagement iiberwacht und nur bei Be- 
darf in das Fahrzeug geladen werden. Das Herausnehmen 
einer Komponente, um die betreffende Ressource wieder 
fieizumachen, wird im Rahmen der dynamischen Kompo- 
55 nentenverlagerung ebenfalls durch den ChaiServ^ unter- 
stiitzt Durch die Implementierung in Java wird eine hohe 
PlattformunabhSngigkeit erreicht. Komponenten k5nnen in 
einer Komponentendatenbank in der fahrzeugextemen In- 
frastruktur gespeichert und bei Bedarf in die entsprechenden 
60 Systeme geladen werden. Die Komponenten sind vorzugs- 
weise unter objektorientierten Gesichtspunkten modelliert 
und impiementiert und ahneln dabei den Java "Servlets", die 
dazu verwendet werden, die Funktionalitat der Serverseite 
auf einfache Art zu erweitem, siehe fiir die allgemeine EDV 
65 die VerGffentlichung "Servlets" von Sun Microsystems, In- 
ternet-Seite "http://java.sun.com/products/java-server/ 
servlets". Die Kommunikation zwischen den Komponenten 
basiert auf der Java-RMI. 
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Methoden von Komporienten, die im Kontext des Chai- 
Servers laufen, werden mittels HTTP aufgerufen, siehe J. 
Moi^an, "The HEHAW Invocation Model, Broadband In- 
formation Systems, Hewlett-Packard, Palo Alto, 1997. Die 
Verwendung von HTTP hat den Vorteil, daB es fast Oberali 5 
unterstutzt wird und auch "Fiiewails" Ubertragbar sind. 
Durch die oben erwahnte Adressierung und Aufrufsyntax 
mittels "unifonn resource locator" (URL) wird die ge- 
wunschte Ortstransparenz erreicht. 

Fig. 11 zeigt einen diesbezuglichen Anwendungsfall mit 10 
einer Beispielkomponente 57, die auf einer Fahrzeug-Ma- 
schine 58 ausgefuhrt wird. Die Komponente 57 stellt eine 
Methode "Foo" zur Verfugung, die mit einem String- Argu- 
ment aufgerufen wird. Das Ergebnis der Methode kann ein 
HTML-Dokument sein. Die HTTP-Aufrufsyntax beinhaltet 15 
dann bei einem Aufruf 59 durch eine andere Komponente 60 
die Adresse der Fahrzeug-Maschine 58, die Bezeichnung 
der Beispielkomponente 57 und die Angabe der Methode 
"Foo" mit "html"-Charakterisierung. 

Die obige Beschreibung eines vorteilhaften Ausfuhrungs- 20 
beispiels und moglicher Modifikationen hiervon macht 
deutlich, daB das erfindungsgemaBe verteilte Fahrzeuginfor- 
mationsveraibeitungs- und Fahrzeugsteuersystem eine flexi- 
ble und dynamisch anpaBbare Umgebung filr fahrzeugbezo- 
gene Dienstanwendungen bereitstellt Die objektorientierte 25 
Modellierung und einfache Kombinierbarkeil der Kompo- 
nenten durch ihreeinheitlichen Schnittstellen erlauben einen 
raschen und einfachen Aufbau neuer Dienste. Durch die zur 
Systemlaufiseit mdglicbe Verlagerung von Komponraten 
zwiscben Fahizeug und f ahrzeugextemer In&astruktur kann 30 
sich das System optimal den sich dynamisch Sndemden 
Randbedingungen in der Infrastruktur anpassen. 

Patentanspruche 

35 

1. Verteiltes Fahrzeuginformationsverarbeitungs- und 
Fahrzeugsteuersystem mit 

- wenigstens einem fahrzeugseitigen, ersten Sy- 
stemteil (la) und wenigstens einem weiteren, 
zweiten Systemteil (2a, 3a), die jeweils zur Aus- 40 
fiihnmg einer oder mehrerer fahrzeugbezogener 
Anwendungsfunkdon eingerichtet sind und mit- 
einander Uber ein Dateniibertragungsnetzw^k (4) 
kommunizieren, 

dadurch gekennzelchnet, daB 45 

- die Systemteile (la, 2a, 3a) einen komponen- 
tenbasierten Aufbau aus verschiedenen, miteinan- 
der kommunizierenden Komponenten (AKi, . . .) 
zur Ausfuhrung unterschiedlicher Funktionen be- 
sitzen, bei dem jede Komponente eine Funktions- 50 
au&uf-Schnittstelle (5a), liber welche die von der 
Komponente ausgefiihrte Funktion von anderen 
Komponenten desselben oder eines anderen Sy- 
stemteils aufrufbar ist, und eine Konfigurations- 
Schnittstelle (5b) aufweist, uber die ihre Konfigu- 55 
ration variabel festlegbar ist, wobei eine Konfigu- 
rationsmanageieinheit (KM) vorgesehen ist, wel- 
che die Komponenten iiber ihre Konfigurations- 
Schnittstelle in Abhangigkeit davon kontiguri^ 
welche anderen Komponenten im System vorhan- 60 
den sind. 

2. Verteiltes System nach Anspruch 1, weiter gekenn- 
zeichnet durch einen den Komponenten des jeweiligen 
Systemteils zugeordneten Komponenten-Lader (KL). 

3. Verteiltes System nach Anspruch 1 oder 2, weiter 65 
dadurch gekennzeichnet, daB die Komponenten eines 
jeweiligen Systemteils funktionsohentiert hierarchisch 

in eine Anwendungs-Komponentenscfaicht, eine 
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Schnittstellen-Komponentenschicht und eine zwi- 
schenliegende Aggregations-Komponentenschicht 
gruppiert sind. 

4. Verteiltes System nach einem der Anspruche 1 bis 

3, weiter gekennzeichnet durch Mittel zum dynami- 
schen Verlagem einer oder mehrerer Komponenten 
(33) w^rend der Systemlaufzeit zwischen verschiede- 
nen Systemtdlen (31, 32). 

5. Verteiltes System nach einem der Anspriiche 1 bis 

4, weiter dadurch gekennzeichnet, daS je zwci Anwen- 
dungs-Komponenten nach einem schnittstellenbasier- 
ten ModeU direkt oder nach einem ereignisgesteuerten 
ModeU uber eine Datenhaltungs-Komponente (50) 
kommunizieren. 
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